iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 29
1
DevOps

誤入 Ops 叢林的 Dev 小白兔系列 第 29

從系統架構透明度來看 DevOps

  • 分享至 

  • xImage
  •  

看著今天挑戰第 29 天,不小心以為是今天燃燒第 29 天,我想我一定是累了...話說行百里半九十,就快到終點了!!吶喊前進!!就在我差點斷炊的時候,讓我想到最近處理的一個事件,我覺得跟 DevOps 也滿有關的。

事情是這樣的,因為機器資源管理的需求,所以我們收到系統單位的通知,希望我們有兩台網頁的機器可以暫時關機,讓他們做搬移後再重啟,時間大約是十分鐘,再加上我們的檢查時間,我們估計大約會需要 20 分鐘,這個網頁服務是當客戶反應線路有問題時,讓維運人員可以直接透過網頁介面調整線路的服務。

於是我們跟系統單位約定好時間後,告知維運團隊在某個時間區段,請暫停使用後臺服務,當然,我們有挑選客訴相對少的時間,以往維運團隊會說沒問題,如果暫停服務的當下有客訴,他們會直接請我們協助調整,但這次值班的人給了不一樣的回應,是直接回應「那這樣有客訴不就不能處理?有其他的替代使用方式嗎?」,然後這次配合的開發人員也給了另一個回應「你可以先改用某某網址來連?以達到你要的使用目的」。

我不解地詢問回覆的開發人員:「為什麼某某網址也可以使用相同服務?」
開發人員:「那是 API 機器,只是也有放上網頁服務的程式,可以暫時讓對方先使用」

跟以往小小的不一樣,讓我想到是不是我們在架設服務時,除了考慮負載平衡以外,也要考慮當機器需要維修/搬移時,執行方式是否可以讓使用者無感,要準備好替代方案,又或者是在設計架構時,就跟相關單位密切討論,把資源分散在不同地方,而不是單純的依賴系統團隊,隨意配置。

這樣一說,我又想到曾經發生過的案例是當機器發生問題時,開發工程師請維運單位把機器拉下線,開發工程師以為負載平衡下還有其他機器可以提供服務,但實際上其他台機器可能因為其他因素在前幾天已經被拉下線,而維運工程師也沒有仔細考量,接到需求就執行,於是就造成更嚴重的服務異常。

想這類的問題,如果可以把系統的資訊整理好呈現,讓系統單位、維運單位甚至是開發單位都可以對整體架構配置一覽無遺,共享資訊,我想應該可以有更理想的配置,處理問題也可以更加順暢。


上一篇
大膽假設小心實驗(2/2)
下一篇
我在連續30天發文中學到的 DevOps
系列文
誤入 Ops 叢林的 Dev 小白兔30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言